Business processes for Web Services: Principles and applications

PROCESSES IN BPEL A BPEL abstract process provides a description of a related range of behaviors; one can think of it as representing a set of executable processes. Abstract processes have access to the same range of syntax and semantics as executable BPEL processes. Opaque tokens enable explicit hiding of information, and in some cases, may themselves be omitted. In BPEL4 V1.0, the only opacity allowed involves variable references on activities that exchange messages and opaque data assignments. In the next version, there will be three types of opaque tokens: activities, expressions, and attributes. It was soon realized that the meaning of these opaque tokens and the restrictions on them vary greatly based on the use case one has in mind. The new approach in BPEL V2.0 is about the base and profiles. A base defines basic requirements of all abstract BPEL processes. An abstract process profile defines the allowed subset of the syntax of the base, a URL to identify processes belonging to that profile, and the allowable executable completions. The executable completions consist of the set of executable processes whose behavior the profile represents. Two profiles are being defined: one for creating process templates that can later be expanded for specific scenarios, and the other for observable message exchanges. The rest of this section focuses on the newer, more flexible approach to abstract processes. The base consists of the full syntax of executable BPEL, but allows all expressions, activities, and attributes to be opaque. If a syntactic token is mandatory by the XML Schema, then its omission means that it is opaque. The base also mandates that every abstract process must be flagged as such, be schema verifiable, and have at least one valid basic executable completion. This is an executable BPEL file created by replacing every opaque token in the abstract process with a corresponding nonopaque token (including those tokens made opaque through the omission shortcut). A profile addresses a particular usage area of BPEL abstract processes. For example, a templating profile could only allow replacing opaque tokens, whereas a message-exchange behavior profile could allow addition of new activities in arbitrary places as long as they do not interact with the existing partners of the abstract process. Patterns for using abstract processes People often relate abstract processes to other processes that are either more general or more detailed. In this section, we present several patterns 8 that help clarify how abstract processes may be used. These patterns will not be included in the specification. Export pattern—In the export pattern, an abstract process is created from one or more executable or other abstract processes by abstracting (through making opaque or simply deleting) parts that are not relevant to the behavior one wishes to expose. For example, one may use an abstract process to represent common behavior in a set of executables and drop any nonshared behavior. An executable process of a more general business model may need parts tagged as points of variability, and those are made explicitly opaque. In another case, one may teach a business partner the interactions that the partner must follow, in which case the interactions with all other partners are ignored. Import pattern—In the import pattern, an abstract process is used to create either one or more executables or one or more abstract processes that are refinements of the original process. For example, a user needs to create an implementation of an abstract process provided as a behavioral prescription for complying with a known, domainspecific business function. The abstract process may have been purchased from a consulting firm KHALAF, KELLER, AND LEYMANN IBM SYSTEMS JOURNAL, VOL 45, NO 2, 2006 430 as a model of an optimized approach to a problem. The implementation can be created in a series of iterative refinements to the abstract process. Protocol matching pattern I (mirror-image)—In this case, one constructs the process of a particular partner from a given abstract process that the partner needs to interact with. Then, the import pattern can be used to create an executable artifact from that abstract. Protocol matching pattern II (search)—This pattern uses one abstract process to search for another process (in a repository of processes, for example) that can perform the same steps as it can. It is easiest to find an exact replica, but that is extremely unlikely as the processes have probably been created by different people. Protocol matching pattern III (compatibility)—This pattern checks whether several abstract processes can work together. Using abstract BPEL processes Abstract BPEL processes seem to be more difficult to understand than executable BPEL processes. This section covers some research work and case studies involving abstract BPEL processes in order to provide a more concrete understanding of their use. Abstract processes for compatibility and search The usage patterns for the abstract processes above relate processes to each other. Notions of equivalence and simulation in process models and software artifacts are not new: different ones 9 have been proposed over the years based on the class of problems being addressed. For Web Services and BPEL in particular, there is ongoing work in checking properties between processes.processes for compatibility and search The usage patterns for the abstract processes above relate processes to each other. Notions of equivalence and simulation in process models and software artifacts are not new: different ones 9 have been proposed over the years based on the class of problems being addressed. For Web Services and BPEL in particular, there is ongoing work in checking properties between processes. Using a Petri-net mapping of (relevant parts of) BPEL processes, Martens proves such properties as consistency between processes 10 and uses one process to search for required behavior in a repository. 11 In Reference 10, a syntactic approach for consistency is discarded in preference to one that is based on the behavior of the processes at hand. The main concern here is externally visible behavior from exchanged messages. After converting the BPEL process to a Petri net, a communication graph (c-graph) is created and then used in a consistencychecking algorithm. Intuitively, two processes are consistent for Martens if one can be replaced by the other without requiring changes to the environment in which they interact. Here, the executable process must receive at least the messages that the abstract process can receive, but may accept more because of additional functionality not used by the environment. On the other hand, it cannot send out more messages than the abstract process does because the environment is unable to consume them. This work focuses on a subset of BPEL and makes certain assumptions about queuing of messages that are not generally accepted in the industry. In Reference 12, new notions of observable equivalence for workflows are presented (not focusing on BPEL) with and without different classes of silent actions. Abstract processes have been used to search for desired functional behavior in a repository. Most Web Services repositories provide WSDL-based, not behavioral, search. Reference 13 presents a searchby-example approach in which the searching partyprocesses have been used to search for desired functional behavior in a repository. Most Web Services repositories provide WSDL-based, not behavioral, search. Reference 13 presents a searchby-example approach in which the searching party & BPEL can be viewed as an export format, and some refer to it as ‘‘the PDF of business processes’’ & provides a query containing a service’s desired behavior. Another approach better suited to searching for concurrent, multipartner communication (Reference 14) publishes operating guidelines for each partner of the process instead of a single behavioral definition (abstract process) of the process itself. Although creating tools and algorithms for checking relations between different BPEL process definitions is a very active research area, the results do not converge yet to any single unified approach. 12, 15–17 Standard interfaces for electronic commerce RosettaNet is a consortium dedicated to standardizing interfaces for electronic commerce between supply chain partners. To encode the business interactions required to perform a particular business function, such as processing a purchase order or inquiring about a price, RosettaNet defines Partner Interface Processes (PIPs). 18 A PIP definition consists of a textual description, message Document Type Definitions (DTDs), and QoS requirements (time-outs, security, etc.). PIP messages are packaged, routed, and transported by a RosettaNet Implementation Framework-compliant system. IBM SYSTEMS JOURNAL, VOL 45, NO 2, 2006 KHALAF, KELLER, AND LEYMANN 431 Work is under way in RosettaNet to determine whether the framework can be extended to existing messaging protocols and infrastructure, and in particular to Web Services. An approach for porting RosettaNet to Web Services is described in Reference 19. We have used BPEL to represent the business logic in a PIP. 20 A BPEL abstract process encodes exactly the business behavior of one party, as defined in the PIP documents; message exchanges and their ordering are represented by using flow, links, and the messaging activities in BPEL. RosettaNet timeouts and the associated faults are represented using alarm, fault, and event handlers. QoS issues such as reliable message delivery and security are pushed down to the appropriate layers of the Web Services stack. From the abstract process, an executable process may be derived by using simple rules to be executed by the partner. PIP processes for various behaviors follow certain known patterns, such as the asynchronous twoaction PIP or the asynchronous one-action PIP, with clearly defined points of variability; therefore, in Reference 20, we propose the template!specialize! implement approach to PIP definitions. The first step is the most abstract—‘‘template’’ processes are defined for each of the patterns with clearly defined points of variability (e.g., a template for all twoaction PIPs). The template can be specialized by specifying additional details, resulting in abstract processes for a particular pattern (e.g., a purchase order two-action PIP). Finally, simple completion rules are provided for creating executable processes. ADDING QUALITY OF SERVICE USING WS-POLICY The specifications and standards of the Web Services stack are designed to be modular. One can use just the subset necessary for the task; additional functionality can be modularly and noninvasively added at will. The Web Services Policy Framework (WS-Policy) 4 provides a pluggable mechanism for attaching nonfunctional requirements to different parts of other Web Services specifications in a declarative manner. Most commonly, such policies are attached to a WSDL definition. In addition to providing clients with functional service requirements, one can now attach QoS requirements either to a portType, or just to a particular operation. Domain-specific policy languages currently exist for reliable messaging and security. Although a syntax for distributed transaction policies is presented in Reference 21, it has not been released yet as a formal proposal. A policy attachment can contain references to several different policies (reliability, security, etc.); these may be combined by using Boolean operators and may be tagged as either required or optional. Some examples of work that specifically uses WSPolicy attached at the WSDL level are presented in References 22, 23, and 24. In Reference 24 the issues involved in using Web Services policies are discussed and illustrated through the architecture of a prototype that configures policies on a per-interaction basis. Policy-based support is integrated in the Colombo prototype as described in Reference 23. In Reference 24, the authors define the GlueQoS policy language and present a middleware system to support it. GlueQoS is an extension to WS-Policy and is geared especially to cases where policies change during the lifetime of a service. In the standards arena, Web Services Metadata Exchange is being proposed as a specification for handling dynamically changing policies. For example, the policy below indicates the use of reliable messaging with a retransmission interval of 4 seconds and a time-out interval of one hour: ,wsp:Policy wsu:Name1⁄4"tns:RMPolicy" .